home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000061_icon-group-sender _Wed Jun 3 08:17:46 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA00846
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 3 Jun 1998 08:17:46 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA09051; Wed, 3 Jun 1998 08:17:39 -0700
  7. Message-Id: <s5751c70.061@housmtp.oceaneering.com>
  8. X-Mailer: Novell GroupWise 4.1
  9. Date: Wed, 03 Jun 1998 09:49:31 -0500
  10. From: Charles Hethcoat <CHETHCOA@oss.oceaneering.com>
  11. To: icon-group@optima.CS.Arizona.EDU
  12. Subject: Retrieving directory contents -Reply
  13. Mime-Version: 1.0
  14. Content-Type: text/plain
  15. Content-Disposition: inline
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 2707
  19.  
  20. "Richard A. O'Keefe" <ok@atlas.otago.ac.nz> said:
  21.  
  22. |Richard> A directory-with-file-attributes is NOT
  23. a sequence of text
  24. |Richard> lines; it is NOT a sequence, and its
  25. elements are NOT lines of
  26. |Richard> text.
  27.  
  28. >>> Paul Abrahams <abrahams@acm.org> 1998 Jun 01,
  29. 09:45pm >>> said:
  30. >What I care about more
  31. >than anything else is seeing *some*
  32. >system-independent method of
  33. >retrieving the names of the files in a given
  34. >directory.
  35.  
  36. I think each of these gentlemen makes good points.
  37. File and directory names are a problem, but a
  38. bigger problem is the one of locating stuff (host
  39. machines, servers, users, files, and devices like
  40. printers) in general.
  41.  
  42. Where I work, we run PCs with Windows of various
  43. flavors, Netware with NDS and bindery emulation,
  44. and NT network with its means of naming things. 
  45. We also have TCP/IP and its addressing methods. 
  46. In addition, I run Linux. Accessing all this from
  47. an Icon program isn't very easy.  I haven't
  48. figured out a good and reasonably universal
  49. answer, and it sounds like a lot of people have
  50. the same problem.
  51.  
  52. Leaving aside a moment the question of what is a
  53. good way to represent these directories in Icon, I
  54. think the fundamentally correct answer is to find
  55. a consistent, publically available programming
  56. interface to all of these file and directory
  57. systems that were designed by different parties at
  58. different times for different reasons.
  59.  
  60. So I would ask the Icon group to think about how
  61. all these system naming collisions and conflicts
  62. might be reconciled in a sensible way--so that
  63. programs that access them can work no matter what
  64. system they run on, and in a vendor-independent
  65. manner.  (Netware and Microsoft, maybe others, are
  66. competing to define "the" correct way of doing it,
  67. but who knows whose ox is being gored in the
  68. process?)
  69.  
  70. I think Linux already has a good answer.  Its
  71. /proc "virtual filesystem" is a clean and
  72. undemanding way to put system-dependent
  73. information up for programmers (meaning their
  74. programs) to access.  The kernel's internal data
  75. certainly isn't all string-based, but /proc makes
  76. it look that way.  It is easy for a relatively
  77. unsophisticated programmer to understand what is
  78. being offered and to access it without having to
  79. know how the internals work.  No language changes
  80. are required to do this; just a one-time hack to
  81. link this hypothetical /proc-like API into the
  82. Icon interpreter and you have it.  Then all you
  83. have to do in your Icon program is open the
  84. appropriate /proc subdirectory and read it using
  85. the existing facilities in the language.
  86.  
  87. The question is, can the Icon community come up
  88. with this API once for every platform?  (Linux
  89. source is available as a model.)
  90.  
  91. Charles Hethcoat
  92. chethcoa@oss.oceaneering.com
  93.  
  94.